I can't comment on it, but a few lines above we have:

        except LossySetitemError:
            # current dtype cannot store value, coerce to common dtype
            nb = self.coerce_to_target_dtype(value)
            return nb.setitem(indexer, value)

Is it theoretically possible that the dtype cannot store the value, but that the astype operation can still be done with a view? And should we in that case pass through using_cow=using_cow to the recursive setitem call?

I can't directly think of a case (maybe an EA that is backed by object array but can't hold the object you are setting?), but maybe the safest option is to just pass it.

Hm I was thinking about it this as well, but I could not think of a case where we would get a LossySetitemError and then would not make a copy in the astype. Can add it if you prefer anyways

It seems we have a mix of using type(self)(..) and self.make_block_same_class(..). The latter avoids having to pass mgr_locs and ndim)

Good idea, switched.

It also doesn't necessarily harm to always do return [self.copy(deep=False)] to avoid the extra if branch?

I think so, but it could also mess up something I am not thinking about right now. I‘d like to keep as is if you don’t feel strongly about it. Could our caching mechanism be a problem (only theoretically, because we should clear the cache when getting here I think), but there might be edge cases we are missing right now

It's fine to leave as is for now. It will also be an easy clean-up once CoW is enforced.

Yep exactly my thinking as well

We don't need to shallow copy if we already did a hard copy above?

Ah, but the intermediate block will go out of scope, so making a shallow copy here will still only have a single ref in that case?

Exactly, it does not hurt, that’s why I wanted to avoid making the check more complex